說實在的，對於本身就會寫程式的開發者來說，用Bolt的Flow Graph給予行為是比寫程式碼更加花時間的。然而，這並不會減低學習、了解Bolt的意願，事實上這或許是更應該去被仔細思考的。
從專案開發的角度去看，專業分工概念是很重要的，但從專業分工而延伸出來的職能分工，卻不一定是最有效的協做方式。比方說遊戲專案，可以很簡易的將開發分成程式人員、企劃人員和美術人員。而整個專案的開發則是依據這個分工方式循環堆疊上去，進而完成。團隊規模愈大，分工愈細，而規模愈小，則一人多工的需求性則提升。
專業分工本身的存在是很重要的，但從專案來看，產品的完成看的是整體，也視為一體，從而延伸出來的職能分工卻於多數時間裡限制了開發能量的聚合。從實際的開發現況來說，多數小規模的開發團隊會很制式化的去切分開發上的事務。像是美術人員只需繪圖、建模，企劃人員只需撰寫表格、文件，而程式人員則負責處理所有功能的實現。
這裡先強調，在不同的團隊規模、專案類型、人能能力的考量下，沒有一種完美的製作公式，事實上只要能夠完成令自己團隊滿意也讓玩家滿意（說到底還是投資人滿意）的產品，都可謂相當成功的團隊。但對於尚未達到這樣境界的團隊，在摸索中，可以嘗試著跳脫現有的開發思維，或許會成為成功的契機。
而類似Bolt這樣的視覺化工具提供其中一種可能性，一種讓專業分工為基礎但不受職能分工的限制，使多數人員都可賦予專案更多元的行為，擴展其可能性。在Bolt的協助下，不再只有程式人員可以給予功能，跨領域的人員（甚至不是開發專門的人員）都可以將自己的想法以實際的行為加入於專案，使專案更加的豐富，充滿更多的開發能量。
Bolt的Flow Graph就提供了這樣的機會，雖然仍需要一定的學習時間，但圖像式的呈現，讓多數以右腦思考為主的人員容易切入。這就Bolt當時設計的立基點，它不是要改變現有用文字寫程式碼的程式人員的習慣，而是開啓了一扇門，讓非程式人員可進入，進而利用Bolt將行為對等、契合的進入專案。
而藉由圖像式功能給予的基礎上，順利接合程式人員及非程式人員之間的鴻溝，跨越了職能分工的界線，真正的回到了專業分工，緊密協做的可能。
的確，不會因為文字變成了方塊，就讓人瞬間就通盤了解，什麼樣的行為都可以製作、賦予。這中間撇開意願上的問題，時間是最關鍵性的因素。或許可以用方塊式的呈現減少一半的時間，或是更多，但絕不會是跳躍性的立即了解。因此Bolt除了低階的Flow Graph（低階是反應出它和撰寫程式的一對一對應闕係，而非重要度、等級概念），它另外提供了較高階的State Graph。
簡單來說低階的Flow Graph是專注於實現層面的怎麼做面向，也就是How to do。而高階的State Graph則是專注在概念層的部份，也就是What to do。多數非程式人員就算是不了解要怎麼做，但通常對於要做什麼確很有想法。舉例來說
其實細看怎麼做和做什麼，它是一體的二面，唯有二面都實現了，行為才會是功能和設計上都正確。
企劃文字是遊戲專案的核心根本，這是不容質疑的，但文件不可能一筆定調，會反覆的修正。但為什麼修正？多數時是實作後的想法而產生這樣的條正，但從企劃文轉換成可視可玩行為，中間需經過多層次製作，驗證。有時，企劃想要的驗證精度更本不用這麼高，就可以感受到，並進行調整。
或許從企文件到行實現間只要多一層，就可以有效的讓製作更有彈性。
Bolt提供如此的可能性，而不是唯一性。那所謂的做什麼的State Graph，到底能做什麼？
State Graph是依據狀態機概念為基底，而狀態機可說是電腦計算概論中很重要的一個環節，以下的文章可輔助參考
但理論教條並不會讓Bolt顯得更加的高、大、尚。簡單來說，高階層的State Graph可以視為架構核心概念來使用，而低階層的Flow Graph則是提供了一但架構要做什麼後，如何實現具體做法的層次。
尤其是** Finite-State Machines: Theory and Implementation**這裡清楚的顯示了玩家的行為架構。撇開如何實現這稍微複雜的議題，單看學習如何利用概念進行架構，這樣學習時是相當短的，算上工具的使用，也不需要二個星期的間時（就和它人共同學習PlayMaker的經驗，多數非程式開發者於數天內可以完全了解概念加工具的運用）。
接下來當然是在Bolt裡呈現State Graph，今天就先在此打住。
iThome鐵人賽
看影片追技術